%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 10
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 10: Direct Debits (UC14 UC15 UC16)}

In the tenth iteration we will handle the remaining direct debit use cases. We will not decompose an existing component, but add a component to support direct debits. The use cases relevant to this are:
\begin{itemize}
 \item UC14: Set up authorization for direct debits
 \item UC15: Execute direct debits
 \item UC16: Retract authorization for direct debits
\end{itemize}

In this iteration we will thus provide a way for SAB to provide third parties and the customers with a direct debit service.

These drivers can be summarized in the following requirements:
\begin{itemize}
 \item Customers want to handle recurrent payments easily with direct debits but they still want to control access to their bank accounts. 
 
 \item Direct Debit Beneficiaries want to minimize the number of incorrect or delayed payments. Direct debits should prevent this.
 
 \item A direct debit authorisation is set up by the Bank Clerk who has all the information available on paper. The Bank Clerk returns a unique identifier to the Direct Debit Beneficiary and a notification is sent to the Customer's inbox.
 
 \item A direct debit is executed remotely and on demand by the Direct Debit Beneficiary using the unique identifier. There is no standard protocol for this.
 
 \item The validness of the unique identifier is checked before executing the transaction. The Direct Debit Beneficiary is notified when the transaction was unauthorized.
 
 \item Direct debits are executed like regular transactions (UC11).
\end{itemize}





% Insert figure
\begin{figure}[!ht]
    \centering
        \includegraphics[width=0.9\textwidth]{images/It10_UC14_UC15_UC16_componentdiag.png}
    \caption{Component diagram after iteration 10.}
    \label{fig:It10_UC14_UC15_UC16_componentdiag}
\end{figure}



To satisfy these drivers we introduce a \emph{Direct Debit Module} [figure \ref{fig:It10_UC14_UC15_UC16_componentdiag}]. The component has access to bank accounts through the \emph{Customer Information} facade. This is necessary for validation and storing authorisation. The component also has access to the \emph{Send Notification} facade and the \emph{Transaction Processing System}.

To set up a direct debit authorisation (UC14), the Bank Clerk uses the \emph{Employee Web Application} and the information they have available on the paper form. The \emph{Direct Debit Module} validates the information and stores the authorization using the \emph{Customer Information} facade. A notification is sent using the \emph{Send Notification} facade and the Bank Clerk receives a unique identifier associated with the authorization.

The Direct Debit Beneficiary sends a request to the \emph{Direct Debit Module} to execute a direct debit transaction (UC15). A request consists of the unique identifier associated with the authorization, both IBANs, the amount and a reference. Requests are sent with the SOAP protocol over SMTP. Upon request, the component validates the information using the \emph{Customer Information} facade. Afterwards it sends a transaction command to the \emph{Transaction Processing System}. If the request was unauthorized, a message is sent back to the Direct Debit Beneficiary instead.

To cancel a direct debit authorisation (UC16), the Customer uses \emph{SAB Online} to select it from a list of all their direct debit authorisations, provided by the \emph{SAB App Functionality} component. The \emph{Direct Debit Module} is not involved in this use case. 


Requirements can be divided over relevant components as follows:
\begin{itemize}

	\item \emph{Direct Debit Module}
	\begin{itemize}
		\item UC14: Set up authorization for direct debits
 		\item UC15: Execute direct debits
 		\item UC16: Retract authorization for direct debits
	\end{itemize}

\end{itemize}

